Background: Writing patches to fix bugs or implement new features is an important\nsoftware development task, as it contributes to raise the quality of a software system.\nNot all patches are accepted in the first attempt, though. Patches can be rejected\nbecause of problems found during code review, automated testing, or manual testing.\nA high rejection rate, specially later in the lifecycle, may indicate problems with the\nsoftware development process.\nOur objective is to better understand the relationship among different forms of patch\nrejection and to characterize their frequency within a project. This paper describes one\nstep towards this objective, by presenting an analysis of a large open source project,\nFirefox.\nMethod: In order to characterize patch rejection, we relied on issues and source code\ncommits from over four years of the projectââ?¬â?¢s history. We computed monthly metrics\non the occurrence of three indicators of patch rejectionââ?¬â?negative code reviews,\ncommit backouts, and bug reopeningââ?¬â?and measured the time it takes both to submit\na patch and to reject inappropriate patches.\nResults: In Firefox, 20 % of the issues contain rejected patches. Negative reviews,\nback outs, and issue reopening are relatively independent events; in particular, about\n70 % of issue re openings are premature; 75 % of all inappropriate changes are rejected\nwithin four days.\nConclusions: Patch rejection is a frequent event, occurring multiple times a day. Given\nthe relative independence of rejection types, existing studies that focus on one single\nrejection type fail to detect many rejections. Although inappropriate changes cause\nrework, they have little effect on the quality of released versions of Firefox.
Loading....